Environment: File server is running Windows Storage Server 2008 SP2 (Build 6002). Clients are running Windows 7 Professional (Build 7600). Domain Controllers are running Windows Server Enterprise 2003 R2 (Build 3790.srv03_sp2_gdr.100216-1301: Service Pack 2). The clients “My Documents” folder is re-directed to a hidden file server share via Group Policy, and is made available offline at every client. Permissions on the share are configured with all clients having Read and Traverse through the parent share, with the user and administrators being granted full permissions on their username specific share. Problem: About 70% of users are experiencing sync issues with some of their offline files. The problem evidences itself as a Sync Error on that file. The Sync center will report “The system cannot find the file specified” and the file will not be synchronized. Any other files in their ”my documents” that are not listed as having an error in the sync center will synchronize just fine, and be available online and offline as expected. Example: One user has 5,794 files in his my documents. 29 of those files give the “the system cannot find the file specified” error. All 29 files exist on his machine in the local offline cache, and on the server share. The files locally were all modified either today or within the last couple weeks. The files as they exist on the server share have a modified date ranging from weeks to months ago, and do not reflect any recent changes. In researching it appears once the problem begins on the file, it will not sync again. Solutions attempted: · CLIENT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\ OplocksDisabled = 0 FILE SERVER: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks = 1 Result: No Change · HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CSC\Parameters Add Dword “FormatDatabase”, set to 1, reboot. Result: Local cache is wiped, and a new Synchronization is performed without any errors at all. Any file that was reporting the error is reverted to the version that was on the server, wiping out any changes made locally since it was last able to sync. Synchronization will work normally for a week or two, then new files will start popping up with “The system cannot find the file specified”. I have several users with whom I copied the contents of their my documents to a local folder, ran the “formatdatabase” registry key, copied all the files back into my documents to preserve local changes they have made since it last synced, and it did work…..for a couple weeks. Then new files start reporting the error. Anyone have any ideas on this?

Why you would like to hide the shared folder? Does the issue occur if the folder is not hidden? The issue may be caused by it. I suggest you disable SMBv2 on Windows 7 and Windows Server 2008 computers, then check the result. To disable SMB2, please use the following commands. sc config lanmanworkstation depend= bowser/mrxsmb10/nsi sc config mrxsmb20 start= disabled Please note: there's an extra " " (space) after the "=" sign. If the issue persists, please temporary disable antivirus and firewall on the computers.Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Arthur, thanks for you response. Just to clarify "sc config lanmanworkstation depend= bowser/mrxsmb10/nsi" Is this supposed to be "bowser" or "Browser". If I try it with browser it reports "[SC] ChangeServiceConfig FAILED 1059:Circular service dependency was specified." If I try it with "bowser" it says it is successful but bowser looks like a typo to me so I thought I would clarify. Turning off firewall and Anti-virus at the server and client didn't change any files reporting the error. They still report the error. The file share is hidden more just to clean up the share list on the file server and added security, but I won't be able to make that change quickly. I'll need to move a couple users into a test OU, apply a modified group policy with the unhidden sharename on it, and see how thier redicrection acts. I'm worried the files that are not syncing may revert to the unsynchronized server version when we do this. One final question. Should I expect to see files that are not currently synching start to sync when we figure the problem out, or will we have to make all these changes, and then hit the users one by one and re-add that "formatdatabase" reg key to clean up the local cache (ensuring we make copies of the local unsynced files before we do this)?

Aurther, thanks for you response. Just to clarify "sc config lanmanworkstation depend= bowser/mrxsmb10/nsi" Is this supposed to be "bowser" or "Browser". If I try it with browser it reports "[SC] ChangeServiceConfig FAILED 1059:Circular service dependency was specified." If I try it with "bowser" it says it is successful but bowser looks like a typo to me so I thought I would clarify. Turning off firewall and Anti-virus at the server and client didn't change any files reporting the error. They still report the error. The file share is hidden more just to clean up the share list on the file server and added security, but I won't be able to make that change quickly. I'll need to move a couple users into a test OU, apply a modified group policy with the unhidden sharename on it, and see how thier redicrection acts. I'm worried the files that are not syncing may revert to the unsynchronized server version when we do this. One final question. Should I expect to see files that are not currently synching start to sync when we figure the problem out, or will we have to make all these changes, and then hit the users one by one and re-add that "formatdatabase" reg key to clean up the local cache (ensuring we make copies of the local unsynced files before we do this)?

The word in the command is “bowser”. How does it work after disabling SMBv2? You should not need to clear the cache on each computers after you fix the issue.Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Ran the following on both the server and the client: sc config lanmanworkstation depend= bowser/mrxsmb10/nsi sc config mrxsmb20 start= disabled Rebooted, verified firewall and antivirus disabled on both. Files reporting the error still report then error on an attempt to sync. Next step is to do the group policy and share change, I'll work on getting that done and get a result.

I have my test users set up on a non-hidden share, but unfortuantely to clear the existing sync errors, I had to run the "FormatDabase = 1" reg entry. This has the unfortuante side effect of most likely delaying any results by a couple weeks, as that is the normal time frame for these errors to re-appear after that has been performed. I guess we'll have to wait and see if this resolves the problem.

I did move a test group into a different OU and mapped thier my documents to a shared folder that was not hidden. I confirmed documents were syncing properly to the new location. To clear the old location out, I had to run the "FormatDatabase=1" reg command, which cleared the error on the test group. However, the problem has returned to at least 1 user in the test group who does have his my documents mapped to the unhidden share. I'm currently working a trouble ticket with Microsoft on this and I will post our results when we reach the end of that.

Hi guys...not sure if this issue has been closed, resolved or just gone away. I have an issue with a user who appears to get sync failed errors daily. The file types are different, doc, xls, jpeg to name a few, the time stamps are all different, some recently worked on, some un-accessed for up to years, the random nature of it is so very strange. Users Documents are re-directed to DFS homeshare and are always available offline. Clients are running Windows 7 SP1 with Server 2008 R2 severs. Have rolled out a number of machines with what appears little or no issues, though users tend to ignore issues with sync and continue to work on the offline cache version, so not entirely sure if it is more wide-spread. I have delected offline cache and re-created, which seemed to solve the original file issues, but every day there are one or two files which do not sync and error. I have been asking the user to open the offending files and save them to a network share for safe keeping and deleted the originals, re adding the copied versions and things look good. Then next day, different files appear with the same issues, so frustrating, I am pulling my hair out. Any resolution to the original post issue, which mirrors mine as closely as I can find anywhere?

*whew* after working with Microsoft support since late September, we have finally reached the root cause of this issue last Friday. The problem was caused by SMB Version 2 being turned off on the Storage Server 2008 SP2. This had been disabled previously due to slow network file access by one of the admins. Apparently the Windows 7 clients were still trying to utilize smb V2 specific features, and it was causing this issue on document synchronization since they were reverting to SMB V1 due to the server requiring them to. Aurther Xie had asked me to disable SMB V2 in one of the posts during troubleshooting, but unbeknowst to me, SMBV2 was already disabled at the server, which was essentially the root cause of the issue. Apparently disabling SMB V2 at the client station also did not prevent it from triggering the offending SMB V2 specific feature at the client. The following Registry key will disable the SMB V2 feature that was causing this issue at the client station. Since we would have had to add this to every client station, we opted to just re-enable SMB V2 at the server level. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters\ New Dword Value (32-bit) : FileNotFoundCacheLifetime Value = 0 If we added that value at the client station, after a reboot, their files would sync with no issue. Once we re-enabled SMBV2 at the server and rebooted the server, then the client stations, everyone's documents began syncing correctly. We have yet to see a resurgence in the slow network file access as well. Perhaps a hot fix in the interim time has resolved that issue.